Date: Sat, 26 Mar 94 04:30:11 PST 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V94 #82 

To: Ham-Digital 


Ham-Digital Digest Sat, 26 Mar 94 Volume 94 : Issue 82 


Today's Topics: 
Am I normal? 
DPK-9600 info needed 
FROM INTERNET 4597267@MCIMAIL.COM 
mailgateway Packet Radio <--> Internet 
MFJ 1278B tnc problem 
NET_Mac2.3.39.sea.hqx.text 
NTS traffic on packet 
RShtx202/KPC-3 wiring question 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Fri, 25 Mar 1994 19:17:24 GMT 

From: ihnp4.ucsd.edu!library.ucla.edu!csulb.edu!csus.edu!netcom.com! 
greg@network.ucsd.edu 

Subject: Am I normal? 

To: ham-digital@ucsd.edu 


Now that I've gotten the attention of everyone on the net that likes 
a good straight line... 


I'm using a PK232MBX with a Drake TR7. 
In CAL mode, I've followed the directions for setting up the levels. 


But I find the following: 


1. In LSB mode on the transceiver, even though the 
power output looks right, the audio reports are 
bad and the signal sounds at once rough and weak. 

2. On RTTY mode, everything works okay on the air 
(i.e. AMTOR, RTTY, and PACTOR contacts work well, 
with much praise for the subjective signal quality). 
However, while calibrating, I note that when I set 
up for 50 watts out on the low tone, the high 
tone yields over 100 watts out. On LSB, the tone 
levels are within a couple of watts of one another. 


Am I wrong in my assumption that the amplitude of the two tones ought 
to be roughly equal? I guess that if it is so, I might be dealing 

with a problem of audio filter roll-off. On the other hand, I've always 
used the PK232 with FM rigs in the past, and it's harder to spot 
over-deviation than it is the HF rig's obvious difference in power 
output. 


Does the PK232 have some kind of balance pots? I didn't see any information 
in the manual. 


On another cheerful note, I've seen a lot of discussion on the air about 
PACTOR lock-up followed by disconnect, from people using the PK232. 


Date: Fri, 25 Mar 1994 15:54:51 GMT 

From: ihnp4.ucsd.edu! galaxy.ucr.edu!library.ucla.edu!csulb.edu!csus.edu! 
netcom.com!wroth@network.ucsd.edu 

Subject: DPK-9600 info needed 

To: ham-digital@ucsd.edu 


Steve Ford (WB8IMY) (sford@arrl.org) wrote: 

: I recently received a message from a Russian amateur requesting 
: more information about the DPK-9600 modem. The text of his 

: message follows: 


: "I read article about the DPK-9600 modem. It says the DPK-9600 
: features a single-chip FSK modem 4800/9600/19200. It also says 
it is complete compatible with KING and G3RUH modems. 


: Is it really all features of G3RUH (scrambler/descramler, FIR filtr, 


DPLL clock recovery) in single-chip ? What is name of chip ? What is 
: price ? Or maybe it is a some DSP chip with software support for all 
: g3ruh features..? Can you tell me some more about this design in 
DPK-9600 ?" 


I evaluated one for the VITA organization with UO-22 and KO-23. The 
performance on rx was VERY poor. The recieved data rate was about 

20% of my DSP-12. I talked to DRSI, and they acknowledged they had a 
problem decoding packets from the satellites. My findings were duplicated 
by Andy McAllister of AMSAT. 


There is a single chip which seems to handle most of the modem functions, 
but it's propriotary to DRSI I believe. 


I can't speak for the performance on terrestrial packet, DRSI said it 
worked well there. It's unfortunate that it works so poorly with the 
satellites, it's packaged in a tiny case, and draws very little power. 
Aside from the fact it doesin't work, I liked it :). 


73's de WA2N/5 
Wayne Roth 


wroth@netcom.com 


Date: 25 Mar 1994 22:31:01 -0500 

From: ihnp4.ucsd.edu!swrinde! gatech!newsxfer.itd.umich.edu!news1.oakland.edu! 
vtc.tacom.army.mil!vtc.tacom.army.mil!not-for-mail@network.ucsd.edu 

Subject: FROM INTERNET 4597267@MCIMAIL.COM 

To: ham-digital@ucsd.edu 


Before I would buy ANY book, you might want to look around the 
internet. (Eff.org specifically, and rtfm.mit.edu) 


EFF produced and electronic book called "The Big Dummies Guide 


to the internet". It's very good and it's freely available. 
NSIFQ 
Steven E. Grevemeyer Phone: (810)574-5106 FAX: -5008 


Software Enginnering Division (AMSTA-OS) 
US Army Tank-Automotive RD&E Center 
Vetronics Technology Center Email: grevemes%vtc@tacom-emh1.army.mil 


Warren, MI 48397-5000 


Steven E. Grevemeyer Phone: (810)574-5106 FAX: -5008 
US Army TACOM/Software Enginnering Division (AMSTA-OS) 
Vetronics Technology Center Warren, MI 48397-5000 
Email: grevemes%vtc@tacom-emh1.army.mil 


Date: Sat, 26 Mar 1994 08:00:35 GMT 

From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!agate!dog.ee.lbl.gov! 
newshub.nosc.mil!news!news@network.ucsd.edu 

Subject: mailgateway Packet Radio <--> Internet 

To: ham-digital@ucsd.edu 


In article <2mp75£$t71@sun19.tfh-berlin.de> 
menzel@tfh-berlin.de (Olaf_Menzel) writes: 


> I have read in the newsgroup rec.radio... 
> in Amerika you have a mailgateway between Packet-Radio 
> and Internet. 


Is this the case? Suppose I have a packet message I want to have 
delivered to my email address, where should it be sent via packet? 


Suppose the reverse is the case; I have a message here on my computer 
which I want to send to a packet address...where do I send it? 


Roger Keating - KD6EFQ 
keating@nosc.mil 


Date: 26 Mar 1994 00:45:29 GMT 

From: ihnp4.ucsd.edu!dog.ee.1lbl.gov!agate!howland.reston.ans.net!torn!news.unb.ca! 
nbt.nbnet.nb.ca!nbnet.nb.ca!zulu@network.ucsd.edu 

Subject: MFJ 1278B tnc problem 

To: ham-digital@ucsd.edu 


I have just upgraded to Pactor by adding a seperate board to the MFJ 1278. 
This upgrade now turns the tne into a 1278b. 


I noticed after making approx 3 or 4 Pactor contacts that I lost Amtor 
capability. Since the loss didnt occur immediately upon firing up the new 
upgrade, I suspect that it may not be associated with the new board. But I 
dont know, and I dont want to ask the company. 


Has anyone else run into this type of failure. 


Date: 25 Mar 94 15:43:46 GMT 

From: news-mail-gateway@ucsd.edu 
Subject: NET_Mac2.3.39.sea.hgqx.text 
To: ham-digital@ucsd.edu 


The Netherlands, March 25, 1994. 
Hello dear reader, 


Today I distributed the file NET_Mac2.3.39.sea.hqx... 


For those who don't know NET/Mac... NET/Mac is the application that 
supports TCP/IP over packet-radio, which means, that hamradio operators 
can use NET/Mac for their wireless TCP/IP network... 


In this version of NET/Mac I implemented the following: 


- Mods for Power Macintosh models (tested on a 7100/66) 
- OUT windows in a split-window session were sometimes hidden 
- Improved the generation of From addresses for hop-to-hop 


This version obsoletes all versions of info-mac/comm/net/radio-netmac in 
the Sumex-Aim archives. 


The new NET/Mac has (hopefully) been uploaded to: 
1) ucsd.edu, to the directory hamradio/packet/tcpip/incoming. 
If it's not there then look at hamradio/packet/tcpip/mac. 


It may also get uploaded to: 
oak.oakland.edu, to the directory pub/hamradio/mac/digital/???? 
as soon as I know where to put it... 


Kind regards, 


Adam PA2AGA (e-mail: adam@gg.tno.nl  ) 
( Or: pa2aga@gg.tno.nl for letters only, NO BIG files here) 


Date: 25 Mar 94 19:29:43 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: NTS traffic on packet 
To: ham-digital@ucsd.edu 


Danny: 


The ARRL Publications or others on the air/Internet can advise you on how 
packet messages go point-to-point. My comment is addressed to the query," 
How does NTS traffic get handled on the Packet network?" 


I am advised by local packet network managers and the local NTS 
representatives that NTS traffic fares poorly on the packet network. The 
problem is one of "culture" 


The traffic culture was built around HF operations - originaly spark, then 
cw , then voice and cw. When digital modes appeared, particularly AMTOR, 
the NTS began to incoporate that mode for traffic. The traffic culture is 
based upon one person handing traffic to another and the second person 
agreeing to forward or deliver the traffic. The Q-signals reflect this 
since QSL confirms receipt and QSP agrees to relay. 


The packet network culture imitates the E-mail structure of public utilities 
and companies, but has no provision (that I am aware of) for 

automatically acknowledging receipt. This is not in general a limitation 
since most packet messages are sent to someone who is a ham known to be 
connected to the packet network. 


The NTS system does not require that the message receipient be a member of 
the National Traffic System or even to be an amateur. This is where a 
significant problem lies. Because packet network messages are handled in an 
"unattended" fashion, a node on the network may accept a message headed 
into its area which will then be placed in a file awaiting checkin by the 
recipient without agreeing that it will guarantee to relay or deliver. 

The receipient may be a"one-time" or an "infrequent checkin" type and the 
message will languish waiting for them to come and get it. Eventually aging 
causes it to be removed from the active storage. 


Most BBS operators implore those who check in to look at the accumulation 
of NTS messages and accept one or more that they are willing to relay or 
deliver. The problem is that there is not a habit pattern or culture 

that has grown up within the packet community to accept such activity as 
something of interest. In some cases, the persons checking in may not have 
HF priviledges that permit them to off-load the messages to the local 
traffic nets. 


In summary, this is an interesting situation which perhaps offers an 
opportunity for public service. If such a culture were developed, it would 
be in place ready to go in the event of an emergency. Regrettably, to date 
the right ingredients have not come together. 


I hope this long answer helped your understanding of things. 


Best 73 
Tod Olson, KOTO 


Director, Dakota Division 


ARRL 

f--------------------------- f---------------------------------- + 
| Tod Olson, KOTO | E-Mail tao@maroon.tc.umn.edu 

| | MCI address 246-8130 | 
| Tao Enterprises | Voice 1-612-473-6478 

| 292 Heather Lane | FAX 1-612-473-7474 

| Long Lake, MN 55356-9439 | "There are no solutions, just | 
| | different sets of problems!" | 
fo------------------------------------------------------------- + 


Date: Fri, 25 Mar 1994 16:23:41 GMT 

From: agate! howland.reston.ans.net!pipex!sunic!psinntp!psinntp! gdc!evax.gdc.com! 
franzis@ames.arpa 

Subject: RShtx202/KPC-3 wiring question 

To: ham-digital@ucsd.edu 


Mark, 


The HTX202 manual has a section on hooking up a TNC and 
it seems quite simple. 


-Pat niocj 


Date: Fri, 25 Mar 94 18:45:40 GMT 
From: mnemosyne.cs.du.edu!nyx10!nburnett@uunet.uu.net 
To: ham-digital@ucsd.edu 


References <2mnbtp$sr7@hpbab.mentorg.com>, 
<1994Mar23 .180631.11120@mnemosyne.cs.du.edu>, <2mscpg$en5@hp-col.col.hp.com> 
Subject : Re: KPC-3 and TCPIP 


jms@col.hp.com (Mike Stansberry) writes: 


: >KPC-3 is excellent value for the money. 

If you only want to go 1200 baud it's fine and if you want to keep the same 
EPROM in it it's fine. But if you ever want to modify it for high speed 

or DCD or KISS only you'll regret buying as I did. 


VV VV 


>: Just my opinion and expierience, 
>: 73, Nate 


>The KPC-3 already has KISS capability. 


I know notice the word 'only' after KISS. I run a high speed KISS only EPROM 
(kiss 56). 
Nate 


Nathan C. Burnett N8MBK 

AX.25 PBBS n8mbk@wb8h.#semi.mi.usa.na 

AMPRNET n8mbk@wsu.n8fow.ampr.org [44.102.48.2] "Nature cannot be fooled" 
Internet nburnett@nyx.cs.du.edu Richard Feynman 


End of Ham-Digital Digest V94 #82 
KKKKKKKKKKKKKKKKKKKKKKKKEKR KKK AK 


